-
Notifications
You must be signed in to change notification settings - Fork 165
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
new(scap): extend scap machine info, new agent info (new metrics 1/n) #880
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good so far! Left you some points.
userspace/libscap/scap.c
Outdated
{ | ||
gethostname(handle->m_machine_info.hostname, sizeof(handle->m_machine_info.hostname) / sizeof(handle->m_machine_info.hostname[0])); | ||
char *env_hostname; | ||
env_hostname = getenv("FALCO_HOSTNAME"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The env var must not be FALCO_
prefixed, but we'll need to make that a CMake overridable variable. Of course, for Falco as a consumer the name could be FALCO_HOSTNAME
, but other libs consumers might want to have different namings.
Example of how we do this already for another env var:
Line 1316 in b9591d6
char* p = getenv(SCAP_HOST_ROOT_ENV_VAR_NAME); libs/userspace/libscap/CMakeLists.txt
Line 44 in b9591d6
if(NOT DEFINED SCAP_HOST_ROOT_ENV_VAR_NAME)
userspace/libscap/scap.h
Outdated
@@ -948,6 +948,24 @@ uint64_t scap_get_driver_api_version(scap_t* handle); | |||
*/ | |||
uint64_t scap_get_driver_schema_version(scap_t* handle); | |||
|
|||
|
|||
/** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there a specific reason why are we exporting these functions in the libscap public API? Since we already have a getter to retrive machine info, and this info is populated in the handle at init time, I think these could just be internal helpers (scap_int.h maybe?). I would just avoid to further extend the API surface of libscap if not necessary, specially now that we're doing such a great job in its polishing process.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. Also, maybe it's a good time to factor out filling machine_info to a separate function (used for live/udig/nodriver engines)?
userspace/libscap/scap.h
Outdated
uint64_t reserved2; ///< reserved for future use | ||
uint64_t reserved3; ///< reserved for future use | ||
uint64_t reserved4; ///< reserved for future use | ||
uint64_t self_pid_start_ts; ///< Agent start ts in nanoseconds (epoch) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good, but I miss the context on why these were reserved. Maybe because of padding and backward compatibility with something?
My only concern, and broader question, is: will we be able to further grow this struct in the future, when we need more info?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIK it's for future extensibility (so that we don't need another hack while reading scap files). Note that this patch breaks compatibility already (the old/new sizes are very much different) so we need changes to savefile code in this PR.
Personally, I'd rather:
- add the string field after the currently reserved fields (let's keep the reserved ones for future integer vars)
- use an
uint64_t flags
instead of a bool and#define
a numeric constant for the one bit we need so far (BTW we can't usebool
anyway since its size isn't guaranteed to be the same on all platforms and we save this struct directly to disk)
(deep in my patch queue there's another patch that adds stuff to machine_info; it needs just a few bits, like 3 or 4 I think, so maybe it could piggyback on the flags field without adding yet another one and using up a pretty scarce resource)
Thanks for the great initial feedback @gnosek and @jasondellaluce - I see the complications here, let's change it. I wasn't sure anyways where to put this data and how to best expose it with the bigger scap cleanup picture in mind. I like all of your suggestions, @gnosek I'll coordinate with you. |
329cf89
to
b4c1c49
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left some more comments! Also, I'd put emphasis on the discussion at: https://github.com/falcosecurity/libs/pull/880/files#r1104380474
b4c1c49
to
c654917
Compare
Addressed reviewers comments including the request to cleanup machine_info retrieval via a clean function. Would adding the new proposed Plus because of the boot time hiccup decided to retrieve start_time from the agent stat file in order to base CPU usage calculations on that (meaning stat start_time will be used to calculate the elapsed time when referencing sysconf uptime) without needing to rely on procfs time stamps, but I kept that metric too so we can report a constant start timestamp of the agent as it should work on most systems. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good Melissa, thanks for addressing all the concerns. I left few comments, but I think my only remaining big point is to avoid adding all those new functions in scap.h
and just keep there const scap_agent_info* scap_get_agent_info(scap_t* handle);
. You can either add those functions to scap-int.h
or have them defined as static in scap.c
, but my point is simply to avoid having those as part of the exported API unless we have a concrete use case.
537cb0b
to
e9d1d27
Compare
userspace/libscap/scap.h
Outdated
* where the hostname can be equivalent to the Kubernetes pod name. | ||
* Customizable over cmake setup SCAP_HOSTNAME_ENV_VAR. | ||
*/ | ||
void scap_gethostname(scap_t* handle); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should go inside scap-int.h
as well, since it's not really a getter (it contains the logic that sets the value). The hostname is available through the machine info struct anyways.
LGTM, this is my only remaining point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, also had to rebase one more time.
additional machine related info useful for: * host attributions * host kernel attributions * identifiers for new resource utilization metrics logs Signed-off-by: Melissa Kilby <melissa.kilby.oss@gmail.com>
Co-authored-by: Jason Dellaluce <jasondellaluce@gmail.com> Signed-off-by: Melissa Kilby <melissa.kilby.oss@gmail.com>
New uint64_t flag slated to be useful for future extensions, PPM_BPF_STATS_ENABLED as initial use case. Grzegorz also pointed out that a bool would not have been possible given the size isn't guaranteed to be the same on all platforms (scap file capture use case). Co-authored-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com> Signed-off-by: Melissa Kilby <melissa.kilby.oss@gmail.com>
Remove uname_r extraction and instead extract in Falco for resource utilization metrics logs. Minor additional cleanups and renaming. Signed-off-by: Melissa Kilby <melissa.kilby.oss@gmail.com>
Signed-off-by: Melissa Kilby <melissa.kilby.oss@gmail.com>
Co-authored-by: Jason Dellaluce <jasondellaluce@gmail.com> Signed-off-by: Melissa Kilby <melissa.kilby.oss@gmail.com>
Co-authored-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com> Signed-off-by: Melissa Kilby <melissa.kilby.oss@gmail.com>
Co-authored-by: Andrea Terzolo <andrea.terzolo@polito.it> Co-authored-by: Jason Dellaluce <jasondellaluce@gmail.com> Signed-off-by: Melissa Kilby <melissa.kilby.oss@gmail.com>
Co-authored-by: Andrea Terzolo <andrea.terzolo@polito.it> Co-authored-by: Jason Dellaluce <jasondellaluce@gmail.com> Signed-off-by: Melissa Kilby <melissa.kilby.oss@gmail.com>
Co-authored-by: Andrea Terzolo <andrea.terzolo@polito.it> Signed-off-by: Melissa Kilby <melissa.kilby.oss@gmail.com>
Co-authored-by: Jason Dellaluce <jasondellaluce@gmail.com> Signed-off-by: Melissa Kilby <melissa.kilby.oss@gmail.com>
9e50fae
to
f2ff449
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/approve
LGTM label has been added. Git tree hash: b36581820ae161c291a816f4a29e25ef1fa06605
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Andreagit97, incertum, jasondellaluce The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Signed-off-by: Melissa Kilby melissa.kilby.oss@gmail.com
What type of PR is this?
/kind cleanup
Any specific area of the project related to this PR?
/area libscap
Does this PR require a change in the driver versions?
What this PR does / why we need it:
Migrating some lookups useful as identifiers and for new resource utilization metrics from Falco to libscap.
additional machine related info useful for:
scap_machine_info
seems a suitable place for new lookups.falcosecurity/falco#2333
falcosecurity/falco#2222
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?: